home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000014_kane@sonata.cc.purdue.edu_Tue Sep 14 20:41 MDT 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  2KB
  1. Received: from yvax2.byu.edu by maine.et.byu.edu; Tue, 14 Sep 93 20:41:27 -0600
  2. Return-Path: <kane@sonata.cc.purdue.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H2Y9WCVQN491X5C0@yvax.byu.edu>; Tue, 14 Sep 1993 20:39:25 MDT
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H2Y9WA3YJ4934SAE@yvax.byu.edu>; Tue, 14 Sep 1993 20:39:21 MDT
  7. Received: from yvax2.byu.edu by alaska.et.byu.edu; Tue, 14 Sep 93 20:40:37 -0600
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  9.  <01H2Y9VF2M3491X5C0@yvax.byu.edu>; Tue, 14 Sep 1993 20:38:40 MDT
  10. Received: from sonata.cc.purdue.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  11.  <01H2Y9VBWC6O934SAB@yvax.byu.edu>; Tue, 14 Sep 1993 20:38:35 MDT
  12. Received: from prelude.cc.purdue.edu by sonata.cc.purdue.edu (5.61/Purdue_CC)
  13.  id AA23304; Tue, 14 Sep 93 21:38:26 -0500
  14. Received: by prelude.cc.purdue.edu (NX5.67d/NX3.0X) id AA02606; Tue,
  15.  14 Sep 93 21:38:30 -0500
  16. Received: by NeXT.Mailer (1.95)
  17. Received: by NeXT Mailer (1.95)
  18. Date: Tue, 14 Sep 1993 21:38:30 -0500
  19. From: kane@sonata.cc.purdue.edu
  20. Subject: Source-code control
  21. To: misckit@byu.edu
  22. Message-Id: <9309150238.AA23304@sonata.cc.purdue.edu>
  23. Content-Transfer-Encoding: 7BIT
  24. Status: R
  25.  
  26. [Don, this list is being archived somewhere, isn't it?]
  27.  
  28. > Let's make some decisions on basic issues like the
  29. > license, source code control, naming, etc. as well as
  30. > what various individuals would like to contribute.
  31.  
  32. Sounds like a plan.  In my letter about "Copyright & licensing
  33. goals", I (obliquely) talked about source code control: it is
  34. up to the individual developer for her/his own contributions.
  35. I think that this is a reasonable policy.  If one person tried
  36. to "do it all", I suspect that if/when the volume became too
  37. great for that person to handle, we'd fall back on this sort
  38. of policy anyway.  I think it would also save some copyright,
  39. licensing hassle (potentially a big mess).
  40.  
  41. Christopher Kane
  42. kane@cs.purdue.edu